The Transparent Interconnection of Lots of Links (TRILL) protocol is already an international standard protocol. With many years of gradual evolution, the Layer 3 routing technology is applied to the Layer 2 transmission, which realizes the large-scale Layer 2 cloud, meets the growing demands on convergence networks and very large data centers, and builds an excellent and efficient Layer 2 broadcast domain. The TRILL uses the End Station Address Distribution Information (i.e., ESADI for short) as an optical protocol to complete the learning of a Media Access Control (i.e., MAC for short) address of an end station.
The End Station Address Distribution Information (i.e., ESADI for short) protocol is an optical protocol for the learning of an end station which is evolved from an Intermediate System to Intermediate System (ISIS), but has a higher priority compared with a stream learning manner. After the ESADI protocol establishes an ESADI neighbor by means of interactive negotiation with a Link State Protocol Data Unit (LSP) of the TRILL protocol, each Routing Bridge (RB) generates the LSP of the ESADI to carry an end address which can be reached by the RB itself, namely the MAC address, and sends the LSP to the network. Only the RB taking itself as a neighbor saves an LSP packet of the ESADI to form a Link State Database (LSDB). In such as manner, the RB learns the end address of the ESADI neighbor, namely the MAC address. The finally learned MAC ITEM of TRILL is <MAC; nickname (the nickname of RB)>, which means that if a native Ethernet frame needs to be sent to the MAC address, the TRILL protocol can be selected to send it to the RB with the nickname in a unicast way.
The native multi-chassis access is a very common network deployment scenario in a data center; in the scenario, a terminal accesses a network through two or more than two links, interfaces on devices forming a group of multi-chassis link accesses are considered to join the same Link Aggregation Group (LAG), and these devices are considered to be member devices in the same LAG. Specifically for a TRILL network, the terminal accesses the TRILL network through multiple links and multiple edge ingress RBs, and these uplink links and ingress RBs form a multi-chassis group. A link aggregation protocol (for example, IEEE 802.1AX-REV) runs on the RB. The packet sent by the terminal may be encapsulated by different RBs in the multi-chassis group, so when a remote egress RB learns the MAC, the ingress-nickname of the MAC ITEM flip-flops frequently because the same MAC address can learn the mapping of only one overlay network device Identity (ID), which causes the instability of a MAC address table, and even causes disorder of returned flow and packet loss, thereby causing the interruption of a session.
FIG. 1 is a schematic diagram of a network scenario according to the related technology. As shown in FIG. 1, a client side device 1 is connected to both the RB1 and the RB2, then the links of the terminal which are connected to the RB1 and the RB2 respectively form a multi-chassis group. When the client side device 1 communicates with the client side device 3, the two links of the RB1 and the RB2 connected to the client side device 1 form a multi-chassis binding relationship. Firstly the MAC1 on the client side device 1 forms a TRILL encapsulation through the RB1 and then reaches the RB5. The mapping relationship between the nickname of the RB1 and the MAC1 is learned on the RB5. When the flow of the MAC1 reaches the RB5 from the RB2, the mapping relationship between the nickname of the RB2 and the MAC1 is learned on the RB5, and the original mapping relationship between the nickname of the RB1 and the MAC1 is covered. When both the RB1 and the RB2 have the flows of the MAC1 continuously that are sent to the RB5, the MAC1 ITEM on the RB5 is refreshed and covered continuously. In addition, although there are multiple RBs, namely the RB1 and the RB2, that can reach the terminal of the MAC1, the data flow source RB5 only selects one or the RBs as the destination RB to forward data instead of freely selecting both the RB1 and the RB2 to communicate, so the efficient utilization of bandwidth cannot be realized, and the loads of RB1 and the RB2 cannot be shared.
Aiming at the problem in the related technology that the RB is unable to notify a remote RB of a native multi-chassis RB ID when accessing the TRILL network in the manner of multi-chassis access, no efficient solutions are put forward at present.